Closure Under Alpha - Conversion ? ? ? Randy

ion, compute a type for its body in an extended context; to compute a type for an application, compute types for its left and right components, and check that they match appropriately. Lets use the algorithm to compute a type for a = [x: ][x: ]x. FAILURE: no rule applies because x 2 Dom (x: ) x: ; x: valid x: ; x: ` x : ? x: ` [x: ]x : ! ? ` [x: ][x: ]x : ! !? (1) This system fails to derive the intended type ! ! . Notice that ` [x: ][y: ]y : ! ! is derivable, but the system is not closed under alphaconversion of subjects. What went wrong? In directly implementing this system we are taking informal notation too literally: there is no \x" in [x: ][x: ]x; the names of bound variables are not meant to be taken seriously. The rule lda should be read as \in order to type [x: ]M , choose some suitable alpha-representative of [x: ]M , : : :". Formal systems with variable binding are implemented on machines as the basis of programming languages and proof checkers, among other applications. It is clear that the concrete syntax that users enter into such implementations, and see printed by the implementation in response, should be formally related to the implemented formal system. Further, users and implementors need an exact and concise description of such a system; informal explanation is not good enough. The concrete syntax should have good properties. Users of such implemented systems will construct large formal objects with complex binding. The implementation should help in this task, and anamolies of naming such as the small example above make the job more di cult. What do you say to an ML implementation that claims fn x => fn x => x is not well typed? There are several approaches to naming in implementations of formal systems. Perhaps the best known is the use of explicit names, and Curry-style renaming in the de nition of substitution. This technique can (probably) be formalized. The di culty arises when we ignore the distinction between alphaconvertible terms, and treat then as equal. It is well known that one solution to the problems of alpha-conversion is the use of de Bruijn \nameless variables" [dB72]. Although nameless variables have their partisans for use in metatheoretic study, even those partisans admit that the explanation of substitution of a term for a given variable is painful in such a presentation, although it can be, and has been, carried out elegantly [Alt93, Hue94]3. However, the direct use of nameless variables is not a real possibility in pragmatic applications because human users nd it di cult to write even small expressions using nameless variables. It is necessary to translate from named syntax to nameless, and then back again to named syntax for pretty printing, and this translation itself must be formalized. I know of two recent proposals that take names seriously, but avoid the need for alpha-conversion. One proposal, by Coquand [Coq91], follows a style in logic to distinguish between free variables (parameters) and bound variables (variables). This idea has been used to formalize a large theory of Pure Type Systems, including reduction, conversion and typing [MP93]. This formalization does distinguish between alpha-convertible terms, and the typing judgement is indeed closed under alpha-conversion. The other proposal, by Martin-L of [Tas93] goes much further, not only using explicit names, but also explicit substitutions, i.e. making the notion of substitution a part of the formal system (as originally proposed for nameless terms in [ACCL91]). Unfortunately the system of [Tas93], in its current formulation, is not closed under alpha-conversion; e.g. it fails to derive judgement (7) in section 3. Finally, there is a recent proposal [Gor93] of a formalization mixing nameless terms and named variables in such a way that named terms are equal up to alpha-conversion. 1.1 The Constructive Engine The Constructive Engine [Hue89] is an abstract machine for type checking the Calculus of Constructions. It is the basis for the proofcheckers Coq [DFH+93] and LEGO [LP92]. Among its interesting aspects are: 1. the non-deterministic rules of the underlying type theory are converted into a deterministic, syntax-directed program 2. this syntax-directed program implements a relation equivalent to the type theory, but with very much smaller derivations 3. external concrete syntax with explicit variable names is translated into internal abstract syntax of locally nameless terms, that is, local binding by de Bruijn indexes, and global binding by explicit names 4. an e cient technique for testing conversion of locally nameless terms (with special attention to the treatment of de nitions) The basic ideas of the rst and second of these points appeared in early writing of Martin-L of. The rst point has been studied extensively [Pol92, vBJMP94] for the class of Pure Type Systems. The second point is addressed in [vBJMP94, Pol94]. The fourth point (which is clearly the remaining limiting factor in pragmatic implementations of proof checkers) has not received any theoretical attention to my knowledge, although [Hue89, dB85] suggest interesting ideas. 3 For an example of metatheory where nameless variables are very inconvenient, see the discussion of the Thinning Lemma in [MP93] In this note I focus on the third item above, the relationship between concrete syntax and abstract syntax in the Constructive Engine. The use of locally nameless style for internal representation of terms is one of the basic decisions of the Constructive Engine, but perhaps re ects more Huet's interest in experimenting with de Bruijn representation than any ultimate conviction that they are the \right" notation for implementing a type checker. I do not want to study the pros and cons of this representation for e cient typechecking, but only to muse over the relationship between concrete terms, their abstract representations, and their (abstract) types. Plan of the paper. In the next section we discuss simply-typed lambda calculus, !. After presenting several concrete and abstract presentations of its typing rules, we derive a Constructive Engine for !, and consider some variations. In section 3 we consider the same issue for Pure Type Systems (PTS). There is one new problem in the case of dependent types. We explain a constructive engine for dependent types, and show how to make it closed under alpha-conversion of terms. AcknowledgementA careful and knowledgeable referee made many useful suggestions. 2 Simply typed lambda calculus There is a crude way to close the relation ` of the Introduction under alphaconversion of subjects, by adding a rule alpha ` M : ` N : M = N where M = N , alpha-conversion, must also be de ned by some inductive de nition. Such solutions are heavy, and not ideal for either implementation or formal meta-reasoning. Instead of reasoning about three or ve rules, we'll have to reason about all the rules for = as well. Further, rules such as alpha, that are not syntax-directed, are hard to reason about: being non-deterministic, they allow many derivations of the same judgement, which sometimes prevents proof by induction on the structure of derivations. 2.1 A concrete presentation closed under alpha-conversion Another approach is to formalize the informalmeaning of the lda rule suggested above: choose a su ciently fresh variable name to substitute for x. Informally, replace lda by ; y: `s M [y=x] : `s [x: ]M : ! y 62M Substitution of y for x in M must still be de ned, and the usual de nition involves alpha-conversion. We give a formulation suggested in [Coq91] and formalized in detail in [MP93]. Let p, q, r, range over an in nite set of parameters, and x, y, z over variables as before. Parameters and variables are disjoint sets4. De ne two operations of replacement. Replacing a parameter by a term is entirely textual: x[M=p] = x q[M=p] = if p = q then M else q ([x: ]N)[M=p] = [x: ]N [M=p] (N1N2)[M=p] = (N1[M=p]) (N2[M=p]) Replacing a variable by a term does respect the scope of variable binding but does not rename variables to prevent capture: x[M=y] = if y = x then M else x q[M=y] = q ([x: ]N)[M=y] = [x: ](if y = x then N else N [M=y]) (N1N2)[M=y] = (N1[M=y]) (N2[M=y]) Now replace lda by s-lda ; p: `s M [p=x] : `s [x: ]M : ! p 62M (where p 2 M means textual occurrence). In the side condition of this rule, it's not necessary to check that p 62 Dom ( ) because failure of that condition prevents completing a derivation; just choose another parameter, since p does not occur in the conclusion of the rule. It is necessary to check p 62M so that the premiss doesn't bind instances of p that do not arise from x. We could de ne beta-reduction, beta-conversion, prove Church-Rosser, subject reduction, etc. [MP93], but for our purposes alpha-conversion is enough: -refl M = M -lda M [p=x] =M 0[p=y] [x: ]M = [y: ]M 0 p 62M; p 62M 0 -app M = M 0 N = N 0 M N = M 0N 0 Now we can state and prove `s is closed under alpha-conversion 4 Another informality! What is required is that the terms p and x be distinguishable, not necessarily that the underlying objects be. Depending on the formalization of terms we might use weaker conditions. In [MP93], where terms are an inductive type with distinct constructors for parameters and variables, we don't require parameters and variables to be distinct. In informal presentations of logic it is common for \term" to be an inductive relation on strings over some alphabet; in this case, of course, we require that (distinct) objects of the alphabet be distinct. Lemma1 Closure of `s under alpha-conversion. If `s M : and M =M 0 then `s M 0 : This can be proved following the same outline as a proof of subject reduction (closure under beta-reduction); in fact = is contained in parallel reduction, so this lemma is a corollary of subject reduction. `s still treats parameters seriously: `s [x: ][x: ]x : ! ! but p: ; p: 6`s p : : This is a di erent problem, if it is a problem at all. In `s we have analysed the transition from local variable to global parameter, while the treatment of parameters themselves is the same as in `. An induction principle for `s. An interesting variation on the previous idea is to use generalized induction to truly remove the fresh name from derivations. Replace s-lda by g-lda 8p 62 Dom ( ) : ; p: `g M [p=x] : `g [x: ]M : ! Notice again the \side condition", this time appearing as an antecedent of the generalized premiss. We don't exclude those p that happen to occur in M , because we must derive ; p: `g M [p=x] : for in nitely many p (using that the class of variables is in nite), while M can contain only nitely many p. On the other hand, for p 2 Dom ( ), ; p: `g M [p=x] : is not derivable for reasons not having to do with M or , so this case must be excluded. Both `s and `g derive more judgements than `; in fact `s and `g are equivalent. Lemma2. For all , M and , `s M : , `g M : This fact, to be proved, allows us to use structural induction over `g as an induction principle for `s that is stronger than structural induction over `s. Lemma 2 states that `s and `g are extensionally equivalent, i.e. have the same judgements. Consider proving some extensional property, P, of `s M : , by structural induction. In the case of s-lda we must justify P( `s [x: ]M : ! ) from the induction hypothesis P( ; p: `s M [p=x] : ) for some particular p. Using lemma 2 it su ces to justify P( `s [x: ]M : ! ) from the stronger induction hypothesis 8p 62 Dom ( ) : P( ; p: `s M [p=x] : ). Informally, this strength comes from showing that the same judgements are derivable in a system with fewer derivations. It is clear that while there are in nitely many derivations of, for example, `s [x: ]x : ! , each containing some particular parameter, `g [x: ]x : ! has only one derivation that does not contain any particular parameter. Loosely speaking, `g has a \subformula property" that `s lacks. It is this induction principle which justi es our belief that in a judgement `s M : , the occurrence of a parameter in can be treated as binding its occurrences in M , hence the actual parameter used doesn't matter as long as it is su ciently fresh. Such arguments are used many times in the formalization of named variables in [MP93, Pol94], and are used below in justifying the Constructive Engine. Proof of lemma 2. Direction( is by induction on the derivation of `g M : . Direction ) is not so easy. It can be proved by induction on the length of the subject, M , as, for every rule of `g, the subject of the conclusion is longer than the subject of any premiss. Such a proof does not extend to the case of Pure Type Systems to be considered in section 3. Here I give a proof that does extend, and is better than the proof given in [MP93]. [Pol94] describes these three di erent ways to prove such an equivalence in excrutiating detail. We introduce the machinary of renaming. A renaming (ranged over by ) is a function from parameters to parameters such that p = p for all but nitely many p. We extend the action of renamings compositionally to terms and contexts. It's easy to see that bijective renamings respect both `s and `g ; in particular, if is bijective and `g M : , then `g M : . It's a little di cult to construct bijective renamings in general, because not only the parameters that get moved have to be considered, but also those that are xed; a combinatorial nightmare. However it's clear that any renaming that only swaps parameters, e.g. fq 7! p; p 7! qg, is bijective. Now prove `g M : by structural induction on a derivation of `s M : . All cases are trivial except the rule s-lda s-lda ; p: `s M [p=x] : `s [x: ]M : ! p 62M By induction hypothesis ; p: `g M [p=x] : . To show `g [x: ]M : ! by g-lda we need ; r: `g M [r=x] : for arbitrary parameter r 62 Dom ( ). Taking = fr 7! p; p 7! rg, we have ( ; p: ) `g (M [p=x]) : is derivable by renaming the induction hypothesis. Thus we are nished if we can show ( ; p: ) = ; r: and (M [p=x]) = M [r=x]: Notice p 62 Dom ( ) (or the premiss of s-lda could not be derivable), and we also know r 62 Dom ( ). From these observations it's clear that the rst equation holds. For the second equation, notice that if r = p then is the identity renaming, and we are done, so assume r 6= p, and hence r 62M [p=x] (from the premiss of s-lda and the assumption r 62 Dom ( )). Now we use a lemma easily proved by structural induction on terms 8 ;N;M; x : M [ N=x] = (M [N=x]) to reason (M [p=x]) = fp 7! rg(M [p=x]) (r 62M [p=x]) = (fp 7! rgM )[fp 7! rgp=x]) (lemma above) = M [r=x] (p 62M ) as required. ut In the discussion before this proof I emphasised that lemma 2 is about extensional equivalence; we don't expect intensional properties of derivations, such as height, or occurrence of a particular parameter, to be preserved. However this proof is better than the statement of the lemma in the sense that it only renames derivations, leaving their shape intact; every one of the in nitely many branches above a g-lda created by this proof has the same shape. 2.2 Some other systems for ! We are now working towards a Constructive Engine for !, and this will be a system for typing concrete terms with named variables that is closed under alpha-conversion. First we present an optimization that suggests a new idea for handling global variables. Following this idea we will see a presentation of ! not mentioning substitution, that is closed under alpha-conversion. An optimization. I think this optimization rst appears in early writing of Martin-L of, and it is also used in the Constructive Engine. It is interesting for our present purposes because it distinguishes between the variables that have always been global, i.e. bound by the context part of the judgement, and those that have only \locally" become global during construction of a derivation. The inductive de nition of ` is very ine cient in duplicating the test that valid on each branch of a derivation. For example ... x: ! ; y: valid x: ! ; y: ` x : ! ... x: ! ; y: valid x: ! ; y: ` y : x: ! ; y: ` x y : We can optimize ` by moving the test for a valid context outside the typing derivation, that is, test once and for all that the given context is in fact valid, and then whenever a derivation extends the context (using the lda rule), check that the extension preserves validity. o-var `o x : x: 2 o-lda ; x: `o M : `o [x: ]M : ! x 62 Dom ( ) o-app `o M : ! `o N : `o M N : Comparing with `, notice that o-var does not check that is valid, but o-lda does maintain this property during derivations. The sense in which `o is correct is given by Lemma3 Correctness of `o for `. ` M : , ( valid and `o M : ) Thus, in the tiny example above, we only need to check ... x: ! ; y: valid and x: ! ; y: `o x : ! x: ! ; y: `o y : x: ! ; y: `o x y : Both directions of lemma 3 are easily proved by structural induction. However, there is a similar optimization, with a similar correctness lemma, for Pure Type Systems (see [vBJMP94, Pol94]). In that case, where correctness of a context and the typing judgement are mutually inductive, direction) is trivial but direction( is not. It is understandable that the latter is di cult, since it says there is a terminating algorithm for putting back all the redundant information removed from a `-derivation5. The root of the problem We can view the systems presented so far as leaving unspeci ed how a context is searched for the type of a variable. This leaves open the possibility for various implementations, such as linear search, or hashcoding. The price we pay is the requirement for only one binding occurrence of a variable in a valid context. This is actually the root of our problem about closure under alpha-conversion, since we don't restrict to only one binding instance for a variable in a term. Informally our idea is to replace the rule o-var, which does not specify how to search for an assignment to x, by ` x : assoc x which searches linearly (assoc x returns the type of the rst occurrence of x in , viewing as a list that conses on the right). More precisely, we replace o-var with two rules that search from right to left. i-start ; x: `i x : i-weak `i x : ; y: `i x : x 6= y i-lda ; x: `i M : `i [x: ]M : ! x 62 Dom ( ) i-app `i M : ! `i N : `i M N : `i has fewer judgements than `o, for example x: ; x: `o x : but x: ; x: 6`i x : . However only judgements of `o that are incorrect for ` are excluded: if is valid, the order of search doesn't matter. Lemma4 Correctness of `i for `. If valid then `o M : , `i M : 5 I owe this observation to Stefano Berardi. Closure under alpha-conversion. The system `i seems strange: why would we be more operational in presenting an abstract relation than required? The payo is that now the side condition x 62 Dom ( ) of rule i-lda can also be dropped, giving the system of \liberal terms": lt-start ; x: `lt x : lt-weak `lt x : ; y: `lt x : x 6= y lt-lda ; x: `lt M : `lt [x: ]M : ! lt-app `lt M : ! `lt N : `lt M N : We can consider two new relations now, `lt and ( valid and `lt). Notation5. For relation `x, write `lx M : for ( valid and `x M : ), the local version of `x Clearly ` = `li `llt `lt where the containments are proper, as suggested by the following examples y:&; x: ` ([z: ][w: ]w)x : ! (2) y:&; x: `llt ([x: ][x: ]x)x : ! (3) x:&; x: `lt ([x: ][x: ]x)x : ! (4) In ` a variable may not be bound twice on one branch, so judgement (3) is not `-derivable. In `llt, a context must be valid, so (4) is not `llt-derivable, but there is no other restriction on variable re-use. In `lt there is no restriction on variable re-use at all. Notice that `lt M : i `lt M : (where if = x:&; y: ; : : :, then M = [x:&][y: ] : : :M and = &! ! : : : ), while `llt doesn't have this property, which is why `llt is called the local system of liberal terms. With `lt and `llt we have systems for typing ! which are closed under alpha-conversion and require no notion of substitution. (But of course we are also interested in reduction and conversion on the typed terms, and these require substitution.) A criticism of `lt.As I suggested above, the non-operational abstraction \x 2 " that requires x is bound at most once in a valid context, is not well matched to our goal of presenting the typing relation, for the informal notion of term allows the same variable name to be bound more than once, and implicitly contains the idea of \linearly" searching from a variable instance through enclosing scopes to nd the one binding that variable instance. In fact, presentations of type systems in the style of our presentation of `, where validity of a context means any variable name is bound at most once, are very common in the literature (for example [Bar92, Luo90, HHP92]). Why do type theory designers not use presentations in the style of `lt? The problem is that `lt has bad properties of weakening. If ` M : and 0 contains all the bindings of , and is also valid, then 0 ` M : but `lt doesn't have this property. This is a logical property which shows that global bindings should not be treated the same as local bindings. Both ` and `lt treat local and global bindings uniformly: ` is unsatisfactory because it is too restrictive with local bindings, so is not closed under alpha-conversion; `lt is unsatisfactory because it is too liberal with global bindings, so is not closed under weakening. Is `llt just right? 2.3 ! with nameless variables A well-known technique to avoid questions of variable names is the use of de Bruijn nameless variables. Pure nameless terms. Here is a presentation of ! for pure nameless (de Bruijn) terms. db-start ; `db 0 : db-weak `db n : ; `db n+ 1 : db-lda ; `db M : `db [ ]M : ! db-app `db M : ! `db N : `db M N : Notice that there are no real choices to be made: there are no restrictions on the context, and, since there is no ambiguity possible, how we search the context is immaterial. Locally nameless terms. Now consider terms whose local binding is by de Bruijn indexes, but whose global binding is by named variables. As before, x, y range over a class of variables that will be used for global, or free, variables. As usual, we de ne two operations of \substitution" (see [Hue89]) M [N=k] replaces the kth free index with appropriately lifted instances of N , and lowers all free indexes higher than k since there is no longer a \hole" at k. M [k=x] replaces name x with the kth free index, lifting indexes greater or equal to k to make room for a new free index. Here is a system for ! typing of locally nameless terms. ln-var valid `ln x : x: 2 ln-lda ; x: `ln M [x=0] : `ln [ ]M : ! x 62M ln-app `ln M : ! `ln N : `ln M N : This system is very similar in spirit to `s of section 2.1. Its handling of global names is identical to that of `s (and `), and its central feature, the analysis of how a local variable becomes global, is very reminiscent of `s. In particular, any su ciently fresh variable can be used for x in the ln-lda rule, and we can formalize this observation by proving, exactly as in lemma 2, that the judgements of `ln are not changed by replacing ln-lda with 8x 62 Dom ( ) : ; x: `ln M [x=0] : `ln [ ]M : ! From this observation, we have a stronger induction principle for `ln than structural induction, as discussed in relation to lemma 2. Of course `ln is closed under alpha-conversion, because alpha-conversion and identity are the same for locally nameless terms. The Constructive Engine uses `ln as the \kernel" of a system for typing conventional named terms that inherits closure under alpha-conversion from `ln. Locally closed terms. We call a term locally closed if it has no free index occurrences. It is easy to see that if `ln M : , then M is locally closed, and all the type systems for locally nameless terms used below have this property. 2.4 A Constructive Engine for ! Since `ln treats global names just as ` does, we may use the optimization and transformations of section 2.2 on `ln. Analogous to `i we have `iln iln-start ; x: `iln x : iln-weak `iln x : ; y: `iln x : x 6= y iln-lda ; x: `iln M [x=0] : `iln [ ]M : ! x 62M; x 62 Dom ( ) iln-app `iln M : ! `iln N : `iln M N : Similar to lemmas 3 and 4, `ln M : , ( valid and `iln M : ) Again as in section 2.2 we de ne a system of \liberal terms" by replacing iln-lda with ltln-lda ; x: `ltln M [x=0] : `ltln [ ]M : ! x 62M In section 2.2 the step from `i to `lt changed the derivable judgements; in fact `lt is closed under alpha-conversion, while `i is not. In the present case `iln is already closed under alpha-conversion, so the step to `ltln does not change the derivable judgements. The main point is that x occurs in the conclusion of i-lda but not in the conclusion of iln-lda. Lemma6 Correctness of `ltln. `ln M : , ( valid and `ltln M : ) Proof. It su ces to show `iln M : , `ltln M : . Direction) is trivial. Prove direction( by induction on a derivation of `ltln M : using the strong induction principle derived from the fact that ltln-lda can be replaced by 8x 62 Dom ( ) : ; x: `ltln M [x=0] : `ltln [ ]M : ! without changing the derivable judgements, as in the proof of lemma 2. ut The Constructive Engine. We are almost ready to present the Constructive Engine for !. It is (a system of rules for) an inductive relation of the shape ` M )M : . and M are concrete objects with named variables, which we think of as inputs to the engine. M and are the outputs, respectively the translation of M into locally nameless form, and the -type of M in `ltln. For example, the rule for application terms is ce-app ` M )M : ! ` N ) N : ` M N )M N : This is read \to translate and compute a type for the named term M N in context (i.e. to evaluate the conclusion of the rule given its inputs), translate and compute types for M and N (i.e. evaluate the premisses of the rule, whose inputs are computed from the given inputs to the conclusion), and return a result computed from the results of the premisses". We have called such systems translation systems [Pol90]. There is one di culty remaining, with the rule for lambda terms. Following the ce-app example, it should be ; x: ` M )M [x=0] : ` [x: ]M ) [ ]M : ! x 62M but it is not clear how to compute [ ]M from M [x=0]. Reading ltln-lda algorithmically the term [ ]M is the input: to compute its type, strip o the lambda, put a variable x in the hole thus created, (i.e. M [x=0]) and compute a type for this in an extended context. In the translation system this is dualized: given the named term [x: ]M , translate the named term M to locally nameless term M , and then somehow construct a locally nameless version of [x: ]M . To x this problem, we consider one more system, the same as `ltln except that ltln-lda is replaced by pce-lda ; x: `pce N : `pce [ ](N [0=x]) : ! (pce is for pre-constructive-engine) and claim: Lemma7 Correctness of `pce. `ln M : , ( valid and `pce M : ) Proof. It su ces to show `ltln M : , `pce M : . First we have the equations M [0=x][x=0] = M if M is locally closed (5) M [x=0][0=x] = M if x 62M (6) For direction (, if a pce-derivation ends with pce-lda ; x: `pce N : `pce [ ](N [0=x]) : ! (hence N is locally closed) apply ltln-lda withM = N [0=x], using equation (5) and the fact that x 62 N [0=x] no matter what N is. Conversely, assume a ltln-derivation ends with ltln-lda ; x: `ltln M [x=0] : `ltln [ ]M : ! x 62M Since x 62M , using equation (6), apply pce-lda with N = M [x=0]. ut Now we can give the Constructive Engine for !: ce-start ; x: ` x) x : ce-weak ` x) x : ; y: ` x) x : x 6= y ce-lda ; x: ` M )M : ` [x: ]M ) [ ](M [0=x]) : ! ce-app ` M )M : ! ` N ) N : ` M N )M N : This system has a clear operational reading. Further, it has a soundness property: if ` N ) N : is derivable then `pce N : is derivable, for given a derivation of the former, just erase the named terms to get a derivation of the latter. If we show that the translation from named terms to locally nameless terms is correct (I will not do so) the correctness of this engine is established. 3 Dependent Types We will work with the familiar class of Pure Type Systems [Bar91, Bar92, GN91, Ber90, MP93, vBJMP94, vBJ93], which, without further ado, we present as the system of rules in Table 1. A new di culty arises with alpha-conversion in dependent types: the binding dependency of a term and its type may be di erent. For example, we expect to be able to deriveA: ; P :A! ` [x:A][x:Px]x : fx:Agfy:PxgPx (7) but not to deriveA: ; P :A! ` [x:A][x:Px]x : fx:Agfx:PxgPx This example suggests that the rule lda [x:A] ` M : B ` fx:AgB : s ` [x:A]M : fx:AgB ax ` s1 : s2 Ax(s1:s2) start ` A : s [x:A] ` x : A x 62 Dom ( ) weak ` : C ` A : s [x:A] ` : C is a sort or a variable, x 62 Dom ( ) pi ` A : s1 [x:A] ` B : s2 ` fx:AgB : s3 Rule(s1; s2; s3) lda [x:A] ` M : B ` fx:AgB : s ` [x:A]M : fx:AgB app ` M : fx:AgB ` N : A ` MN : B[N=x] conv ` M : A ` B : s A ' B ` M : B Table 1. The typing judgement of a PTS. using the same bound variable for the term and its type is not exactly what we intend. A formalization of PTS that distinguishes between parameters and variables, along the lines discussed in section 2.1, is described in [MP93]. We use the following lda rule: lda ; p:A ` M [p=x] : B[p=y] ` fy:AgB : s ` [x:A]M : fy:AgB p 62M; p 62 B This system has closure under parallel reduction [Pol94]; writing k for parallel reduction we have Lemma8. If ` M : A, k 0, M k M 0 and A k A0 then 0 ` M 0 : A0 Since alpha-conversion is contained in parallel reduction, we have as a corollary Corollary 9. If ` M : A, = 0, M = M 0 and A = A0 then 0 ` M 0 : A0 However this proof, instantiating closure under parallel reduction with the degenerate case of alpha-conversion, is not intensionally satisfactory as it uses the rule conv only for alpha-conversion. A presentation of PTS using nameless terms will never use conv for alpha-conversion, and I would like to know ` is the structurally isomorphic to such a nameless presentation, not just that it has isomorphic judgements. vc-srt `vc s1 : s2 Ax(s1:s2) vc-var `vc x : assoc x vc-pi `vc A : s1 ; x:A `vc B : s2 `vc fx:AgB : s3 Rule(s1; s2; s3) x 62 Dom ( ) vc-lda ; x:A `vc b : B `vc fx:AgB : s `vc [x:A]b : fx:AgB x 62 Dom ( ) vc-app `vc a : fx:BgA `vc b : B `vc a b : A[b=x] vc-cnv `vc a : A `vc B : s A ' B `vc a : B nil-vc `vc cons-vc `vc `vc A : s ; x:A `vc x 62 Dom ( ) Table 2. The system of valid contexts. In section 2.2 we derived a system, `lt, for ! without any variable renaming that was closed under alpha-conversion. I don't think we can do the same for PTS. If we follow the transformations of section 2.2, rst optimizing to only check context validity once, then linearizing context search, we arrive at the system of Table 2. This system is correct, in the sense ` M : A, ( `vc and `vc M : A) If we now try to drop the side conditions x 62 Dom ( ) from vc-pi and vc-lda, as in section 2.2, (call this system `bad) we nd the following incorrect derivation ; x:A; x:Px `bad x : Px ; x:A `bad [x:Px]x : fx:PxgPx `bad [x:A][x:Px]x : fx:Agfx:PxgPx 3.1 The Constructive Engine I remind you that this paper is not addressing the issue of making PTS syntax directed; the Constructive Engine we will derive now is not yet a program for typechecking PTS (in particular, the non-syntax-directed conversion rule remains), but does explain the interaction between named and nameless variables of an operational Constructive Engine. Table 3 is a correct presentation of PTS using locally nameless terms, cor-responding to `iln of section 2.4. Now, as in section 2.4, we may drop the sideiln-srt`iln s1 : s2Ax(s1:s2)iln-var`iln x : assoc x Ailn-pi`iln A : s1; x:A `iln B[x=0] : s2`iln fAgB : s3Rule(s1; s2; s3)x 62 B; x 62 Dom ( )iln-lda; x:A `iln b[x=0] : B[x=0]`iln fAgB : s`iln [A]b : fAgBx 62 b; x 62 Bx 62 Dom ( )iln-app`iln a : fBgA`iln b : B`iln a b : A[b=0]iln-cnv`iln a : A`iln B : s A ' B`iln a : Biln-nil`ilniln-cons`iln`iln A : s; x:A `ilnx 62 Dom ( )Table 3. The intermediate system of locally nameless terms.condition x 62 Dom ( ) from rules iln-pi and iln-lda (getting the system `ltln),just as in lemma 6. Here we are using the locally nameless representation in anessential way for dependent types!Continuing as in section 2.4, we use the argument of lemma 7 to replaceltln-pi and ltln-lda bypce-pi`pce A : s1; x:A `pce B : s2`pce fAg(B[0=x]) : s3Rule(s1; s2; s3)pce-lda; x:A `pce b : B`pce fAgB : s`pce [A](b[0=x]) : fAg(B[0=x])giving a system, `pce, that can be made into a Constructive Engine as in sec-tion 2.4. This Constructive Engine (Table 4) is closed under alpha-conversion. ce-srt` s1 ) s1 : s2Ax(s1:s2)ce-var` x) x : assoc x Ace-pi` A) A : s1; x:A ` B ) B : s2` fx:AgB ) fAg(B[0=x]) : s3Rule(s1; s2; s3)ce-lda; x:A ` b) b : B` fx:AgB ) fAgB : s` [x:A]b) [A](b[0=x]) : fAg(B[0=x])ce-app` a) a : fBgA` b) b : B` a b) a b : A[b=0]ce-cnv` a) a : A` B ) B : s A ' B` a) a : Bce-nil`ilnce-cons`iln` A) A : s; x:A `ilnx 62 Dom ( )Table 4. The Constructive Engine for PTS.References[ACCL91] M. Abadi, L. Cardelli, P.-L. Curien, and J.-J. Levy. Explicit substitutions.Journal of Functional Programming, 1(4):375{416, October 1991.[Alt93]Thorsten Altenkirch. A formalization of the strong normalization prooffor System F in LEGO. In Proceedings of the International Conference onTyped Lambda Calculi and Applications, TLCA'93. Springer-Verlag, LNCS664, March 1993.[Bar91] Henk Barendregt. Introduction to Generalised Type Sytems. J. FunctionalProgramming, 1(2):125{154, April 1991.[Bar92] Henk Barendregt. Lambda calculi with types. In Abramsky, Gabbai, andMaibaum, editors, Handbook of Logic in Computer Science, volume II. Ox-ford University Press, 1992.[Ber90] Stefano Berardi. Type Dependence and Constructive Mathematics. PhDthesis, Dipartimento di Informatica, Torino, Italy, 1990.[Coq91] Thierry Coquand. An algorithm for testing conversion in type theory.In G. Huet and G. D. Plotkin, editors, Logical Frameworks. CambridgeUniversity Press, 1991.[dB72]Nicolas G. de Bruijn. Lambda calculus notation with nameless dummies, atool for automatic formula manipulation, with application to the Church-Rosser theorem. Indag. Math., 34(5), 1972.[dB85]Nicolas G. de Bruijn. Generalizing automath by means of a lambda-typed lambda calculus. In Proceedings of the Maryland 1984-1985 Special Yearin Mathematical Logic and Theoretical Computer Science, 1985.[DFH+93] Dowek, Felty, Herbelin, Huet, Murthy, Parent, Paulin-Mohring, andWerner. The Coq proof assistant user's guide, version 5.8. Technical re-port, INRIA-Rocquencourt, February 1993.[GN91] Herman Geuvers and Mark-Jan Nederhof. A modular proof of strong nor-malization for the calculus of constructions. Journal of Functional Pro-gramming, 1(2):155{189, April 1991.[Gor93] Andrew Gordon. A mechanism of name-carrying syntax up to alpha-conversion. In Proceedings of the 1993 HOL User's Meeting, Vancouver.Springer-Verlag, 1993. LNCS.[HHP92] Robert Harper, Furio Honsell, and Gordon Plotkin. A framework for de n-ing logics. Journal of the ACM, 40(1):143{184, 1992. Preliminary versionin LICS'87.[Hue89] Gerard Huet. The constructive engine. In R. Narasimhan, editor, APerspective in Theoretical Computer Science. World Scienti c Publishing,1989. Commemorative Volume for Gift Siromoney.[Hue94] Gerard Huet. Residual theory in -calculus: A formal development. Jour-nal of Functional Programming, 4(3):371{394, July 1994.[LP92]Zhaohui Luo and Robert Pollack. LEGO proof development sys-tem: User's manual. Technical Report ECS-LFCS-92-211, LFCS,Computer Science Dept., University of Edinburgh, The King's Build-ings, Edinburgh EH9 3JZ, May 1992.Updated version. Seehttp://www.dcs.ed.ac.uk/packages/lego/[Luo90] Zhaohui Luo. An Extended Calculus of Constructions. PhD thesis, De-partment of Computer Science, University of Edinburgh, June 1990.[MP93] James McKinna and Robert Pollack. Pure Type Sytems formalized. InM.Bezem and J.F.Groote, editors, Proceedings of the International Confer-ence on Typed Lambda Calculi and Applications, TLCA'93, Utrecht, pages289{305. Springer-Verlag, LNCS 664, March 1993.[Pol90]Robert Pollack. Implicit syntax. Informal Proceedings of First Workshopon Logical Frameworks, Antibes, May 1990.[Pol92]R. Pollack. Typechecking in Pure Type Sytems. In Informal Proceedingsof the 1992 Workshop on Types for Proofs and Programs, Bastad, Sweden,pages 271{288, June 1992. Available by ftp.[Pol94]Robert Pollack. The Theory of LEGO: A Proof Checker for the Ex-tended Calculus of Constructions. PhD thesis, University of Edinburgh,1994. Available by anonymous ftp from ftp.cs.chalmers.se in directorypub/users/pollack.[Tas93] A. Tasistro. Formulation of Martin-Lof's theory of types with explicit sub-stitutions. Master's thesis, Chalmers Tekniska Hogskola and GoteborgsUniversitet, May 1993.[vBJ93] L.S. van Benthem Jutting. Typing in Pure Type Sytems. Information andComputation, 105(1):30{41, July 1993.[vBJMP94] L.S. van Benthem Jutting, James McKinna, and Robert Pollack. Check-ing algorithms for Pure Type Systems. In Henk Barendregt and TobiasNipkow, editors, Types for Proofs and Programs: International WorkshopTYPES'93, Nijmegen, May 1993, Selected Papers, volume 806 of LNCS,pages 19{61. Springer-Verlag, 1994. This article was processed using theLaTEX macro package with LLNCS style